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1 L-^ 

Optimization of data transfer between networked devices 

FIELD OF THE INVENTION 

The present invention relates to optimization of data transfer be- 
tween networked devices. 

BACKGROUND OF THE INVENTION 

Available wireless local area networking technologies such as the 
Bluetooth technology are widely included In various mobile devices. The de- 
vices are typically allocated an IP (Intemet Protocol) address and they may 
communicate with other devices using the IP protocol stack. Besides desk- 
top/laptop computers and mobile terminals, networking technologies are also 
been Incorporated to various domestic appliances such as TV sets, set-top 
boxes, stereo systems, personal music players, cameras, home management 
systems and fridges. It Is expected that various domestic appliances will be 
capable Interacting with other devices and sharing information using especially 
wireless local area networking technologies and IP-based technologies. 

UPnP™ (Universal Plug and Play) technology by UPnP Fonjm de- 
fines an architecture for peer-to-peer network connectivity of intelligent appli- 
ances, wireless devices, and personal computers of all fonn factors. It is de- 
signed to bring easy-to-use, flexible, standards-based connectivity to ad-hoc or 
unmanaged networks whether in the home, in a small business, public spaces, 
or attached to the Internet. UPnP technology provides a distributed, open net- 
working architecture that leverages TCP/IP (Transport Control Proto- 
col/Internet Protocol) and the Web technologies to enable seamless proximity 
networking in addition to control and data transfer among networked devices 
from a wide range of vendors. According to the UPnP Device Architecture 
(UDA) a . device can dynamically join a networic, obtain an IP address, convey 
its capabilities to other devices, and leam about the presence and capabilities 
of other devices. 

The DHWG (Digital Home Working Group) HNv1 (Home Network 
version 1) specification describes an environment formed by devices like PCs, 
TV sets, set-top boxes, stereo systems, etc. that are connected to the network 
via an IEEE 802.x interface including the Ethemet and the wireless local area 
networic WLAN. The devices forming the HNv1 environment are by their nature 
static or with very limited mobility allowing them to be always connected to an 



2 

AC (Alternating Current) power supply. At the same time the connectivity tech- 
nology they are using allows high data rates and low latency. 

Constrained devices like mobile phones, PDAs (Personal Digital 
Assistant), portable music players or cameras are not typically able to support 
802.x communication technology, but they often deploy energy saving short- 
range communication media such as Bluetooth. Short-range comnnunlcatlon 
media typically exhibits more limited bandwidth and longer delays than in an 
IEEE802.X media. Since these constrained devices or In DHWG terminology 
mobile handheld devices use different communication media than HNv1 de- 
vices, an intenvorking unit is required. Connecting different networks together 
as such is commonly used technology, but the architecture of HNvl exhibits 
communication environment which is problematic for mobile handheld devices 
that have limited energy resources and/or slow communication link. HNv1 
specifies that the UPnP is used as service discovery and controlling protocol 
suite, which potentially and in certain conditions may result considerably 
amount of communication for which the device needs to response. More par- 
ticularly, according to the UPnP discovery protocol the UPnP devices advertise 
their services to other devices in ttie systern by sending multicast messages. 
Further, also services and/or Interested devices may be searched by multicast 
requests. The UPnP specification specifies that a UPnP devfces should send 
each advertisement message more than once due to the usage of unreliable 
UDP (User Datagram Protocol). The result is that the numerous multicast 
messages will consume the battery of the receiving device in rhuch shorter 
time causing unsatisfactory user experience. Also in some conditions consid- 
erably amount of the capacity of the connecting link is used for control com- 
munication preventing using the services available. 

BRIEF DESCRIPTION OF THE INVENTION 

There is a need to alleviate the above disadvantages. The needs 
are fulfilled by a method, a system, a device, a chip, and a computer program 
product which are characterized by what is stated in the Independent claims. 
Some embodiments of the invention are disclosed in the dependent claims. 

The invention is based on the idea of preventing the transmission of 
at least some multicast and/or broadcast messages from a second device to a 
first device by intermediate node an-anging data transmission between the first 
device and the second device. The local area networking system may be any 
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local network configuration. For Instance, It may comprise a Bluetooth network 
and/or an IEEE 802.1 1 WLAN network. 

An advantage of the method and arrangement of the invention is 
that less processing is required in the first device as fewer messages are re- 
5 ceived. Thereby the power consumption of the constrained devices such as 
handheld PDAs, mobile stations, or music players can be reduced. For band- 
width limited links the reduced bandwidth usage is naturally also an advantage 
and thus faster link is available for other data transmission. As the transfer of 
multicast and or broadcast messages Is reduced, the response time of the sys- 

10 tem is faster and average propagation time shorter. Further, the (first) devices 
not receiving multicast messages can still support all functions of the system, 
e.g. full UPnP stack, to be available In case they are connected to the system 
such that multicast messages can be received. This makes it easier to reach 
full compatibility with second device e.g. for enabling connectivity in configura- 

15 tions where there is direct connection between the first and the second device. 
One further advantage of the invention is that it is easy to implement on vari- 
ous technologies thereby enabling to reduce the costs of the end product. 

BRIEF DESCRIPTION OF THE DRAWINGS 

In the following the invention will be described in greater detail by 
20 means of some embodiments with reference to the accompanying drawings, in 
which 

Figure 1 illustrates a local area networking system; 

Figure 2a describes the protocol stack architecture according to an 
embodiment of the invention; 
25 Figure 2b illustrates a device comprising the interworking unit; and 

Figure 3 is a flow diagram illustrating a method according to an em- 
bodiment of the Invention. 

DETAILED DESCRIPTION OF THE INVENTION 

An embodiment of the Invention will be illustrated in the following in 
30 a UPnP system but the invention can be applied also in other networking sys- 
tems in which communication is arranged between handheld like constrained 
devices and devices without such constraints. 

Referring to Figure 1, the system comprises mobile handheld de- 
vices MHD, an Intermediate node, in the embodiment of Figure 1 an inter- 
35 working unit IWU, and home network devices HND supporting the UPnP home 



network version 1 (HNv1) specification. The devices HND form the HNvl dp- 
main and the devices MHD form the MHS (Mobile Handheld Subcommittee) 
domain. The Interworking unit IWU is at the edge of these domains and it pro- 
vides adaptation of the data transmission between these domains. It is to be 
noted that there may also be other devices between the IWU and the MHD 
and/or between the IWU and the HND. The IWU may be a specific device or 
implemented as a part of another device such as a router, an extended bridge 
or a multimedia set top box. In the example of Figure 1, the HNvl domain Is 
using a wired network, e.g. Ethemet, and the MHS domain is utilizing wireless 
networking technology, e.g. Bluetooth. As further shown in Figure 1, it is feasi- 
ble that a MHD may connect with the IWU using a wired link such as USB 
(Universal Serial Bus), and the handheld devices MHD may also communicate 
between themselves and thus form a Bluetooth piconet, for instance. Further, 
the HNvl domain may be connected to other networks such as the Internet. It 
is to be noted that the handheld devices MHD or the HNv1 devices HND may 
comprise also other communication means. For instance, a mobile handheld 
device MHD may comprise the transceiver for communicating with the PLMN 
(Public Land Mobile Networtc). Some examples of devices MHD are PDAs, 
laptop computers, personal music players, headsets, mobile phones and cam- 
eras. HNv1 devices HND are typically always connected to AC power supply 
and some examples of these devices include TV sets, stereo devices and 
home management devices. 

Figure 2a describes one feasible protocol stack architecture for a 
UPnP system. The data transmission link between MHD and IWU (and in one 
embodiment between MHDs) may be provided by well-known Bluetooth PAN 
(Personal Area Network). Information on Bluetooth technology can be found 
from http://www.bluetooth.com/. The data transmission between the IWU and 
the HND may be provided by any IEEE 802-based data transmission technol- 
ogy providing a uniform upper API (Application Programming interface) and 
LLC (Logical Link Control) layer for a number of different MAC (Medium Ac- 
cess Control) and L1 solutions, including the wired Ethemet or 802.1 1 based 
WLAN technologies. The IWU is in one embodiment arranged to remove the 
IEEE 802.x headers from HND-originated packets and to add necessary Blue- 
tooth headers. Reverse actions are done for packets originating from the MHD. 
It is to be noted that the invention may also be implemented by other local area 
networking technologies, some examples of which are BRAN (Broadband Ra- 
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dio Access Networks) specifications (HIPERLAN1, HiPERLAN2, HiPEI^C- 
CESS). A UPnP device MHD, HND supports IP version 4, IP version 6, or 
both. The linic between the MHD and the IWU is according to another embodi- 
ment wired and implemented by USB. 
5 HTTP protocol is used between the MHD and HND above a TCP 

layer (not shown in Figure 2a) to transfer the UPnP layer messages. For send- 
ing and receiving advertisements and search requests according to the UPnP 
discovery protocol, the devices MHD and HND use multicast variant of HTTP 
and for responses a unicast variant of HTTP is used. Both of these HTTP vari- 

10 ants use UDP instead of the TCP. UPnP specific functions are implemented in 
the MHD and HND by UPnP and UPnP AV (Audio Visual) Profile functions; 
Applications and various media formats may then utilize the UPnP functions. 

As illustrated in Figure 2b, the device functioning as the IWU com- 
prises memory MEM, a user Interface Ul, l/O-means I/O for arranging oommu- 

15 nication, and a central processing unit CPU comprising one or more proces- 
sors. Computer program codes executed in the central processing unit CPU 
may be used for causing the device IWU to implement the interworking means 
IWM for arranging transfer of data between the MHD and the HND. Further, 
computer program codes executed in the central processing unit CPU may be 

20 used for causing the device IWU to implement the inventive functions relating 
to the forwarding of messages to the MHD, some embodiments of which are 
illustrated later in association with Figure 3. As one example, the inventive 
functions may be provided as an extension to the application implementing the 
interworking means IWM. A chip unit or some other kind pf module for control- 

25 ling a data processing device (IWU) for a local area networking system may in 
one embodiment cause the device to perform the inventive functions. The 
module may form part of the device IWU and could be removable, i.e. it can be 
inserted into another unit or device. Computer program codes can be received 
via a network and/or be stored in memory means, for instance on a disk, a CD- 

30 ROM disk or other external memory means, from where they can be loaded 
into the memory MEM of the processing device. Hardware solutions or a com- 
bination of hardware and software solutions may also be used to implement 
the inventive functions. 

Figure 3 illustrates a method according to an embodiment of the in- 

35 vention. The method may be implemented in the interworking unit IWU. In step 
301 a message is received. The destination address of the received message 
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is checked 302. According to an embodiment, the IWU compares one or more 
properties of the message to the properties determined In predetemiined mes- 
sage transmission conditions (may be stored In memory MEM) and If they 
match, the message Is depending on the Implementation either forwarxled Or 
5 prevented from being transmitted to the MHD. The IWU may store one or more 
addresses which are pre-detennined In the system as being broadcast or mul- 
ticast addresses. For instance, the IWU may be pre-configured with a list of 
multicast addresses. If the destination address of the received paclcet matches 
with an entry In this list, the paclcet is not transmitted to the constrained device. 
10 in UPnP the multicast address is already specified as being 239.255.255.250 
for all UPnP systems. Based on the chedc 302, 303. if the destination address 
Is a multicast or broadcast address, the tiansmlssion of the message to the 
constrained device, In the example of Figures 1 and 2a to the MHD, is pre- 
vented 304. Otherwise the message Is transmitted 305 to the MHD. The em- 
15 bodiment In which the method Is applied in the IWU enables that no changes 
are necessary to the MHD or the HND. 

Instead of the above-illustrated method, the data transmission be- 
tween the, constrained device (MHD) and the non -constrained device (HND) 
may be ananged also by other means. For instance, after step 301 there could 
20 be an additional checl^ing step In UPnP system on whether the message was 
received on an HKlvl interi^ace. If the message as received on HNvl interface, 
the method would proceed to cun-ent step 302, ottienvise tiie method would 
not be proceeded. Thus only HNvl Interlace packets need to be analysed. 

According to still another embodiment, there can be one or more 
other additional checking steps relating to the receiving device (MHD) before 
entering the step 305. The IWU may check whether the link Is available to tfie 
MHD. For Instance, in case of Bluetooth, the system checks If the BT is in 
"sleep" mode. If it is In the sleep mode, the IWU will wake up the BT before 
entering step 305. If BT is active, step 305 can be directly entered. 

According to an embodiment, not all multicast and/or broadcast 
messages are prevented fliom being ti-ansmitted to the MHD. The IWU may be 
provided witfi message transmission conditions including Information on mes- 
sage types and/or with other message details and the IWU may be arranged to 
check (in step 302/303 or in an additional step preferably before step 302) 
whether the received message complies witti the predetermined conditions. 
This embodiment provides the advantage that possibly very detailed conditions 
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on transfen-ed or blocked messages can be determined, thereby enabling still 
to forward critical messages but preventing the transmission of less important 
messages. This further optimizes the usage of transmission capabilities in the 
system. Depending on the desired implementation, the message complying 
with the conditions may be fonwarded to the MHD or prevented from being for- 
warded to the MHD in case where the conditions determine the blocked or fil- 
tered messages. For Instance, certain types of messages or multicast and/or 
broadcast messages using particular number are fonvarded to the MHD but 
other multicast and/or broadcast messages are not. In UPnP system the 
following embodiment becomes important: The IWU is an-anged only to 
prevent the transmission of multicast messages and It will fonvart at least part 
of or all broadcast messages to the MHD. 

Two general classifications of devices are defined by the UPnP ar- 
chitecture: controlled devices, and control points. A controlled device ftinctions 
15 in the role of a server, responding to requests from control points. Both control 
points and controlled devices can be Implemented on a variety of platfomis 
including personal computers and embedded systems. Multiple devices, con- 
trol points, or both may be operational on the same network endpoint simulta- 
neously. Thus the MHD and the HND in Figure 1 may be arranged to operate 
0 as the controlled device, the control point, or both. 

A UPnP device MHD, IWU or HND may have a Dynamic Host Con- 
figuration Protocol (DHCP) client and it may search for a DHCP server when 
the device is first connected to the network. Altematlvely, the devices autocon- 
figure (Auto-IP) themselves when a DHCP server Is not present in the network 
» The prerequisite for using the UPnP functions is to obtain an IP address (Step 
0). According to an embodiment, the IWU Is arranged to fonn^ard the broadrast 
messages related to address acquisition to the MHD. Broadcast messages are 
used by the address resolution protocol that is used to find out which device 
has a specific IP address. Broadcasts are also used when autoconfiguring the 
system. It is also feasible that some other broadcast messages are fonvarded 
to the MHD, whereas some broadcast messages may be prevented from being 
fransmltted. 

Once an IP address is allocated to a UPnP device, the following 
UPnP functions are available: Discovery is Step 1 in UPnP™ networking 
Through discovery, control points find interesting device(s). Discovery enables 
description (Step 2) where control points leam about device capabilities con- 
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trol (Step 3) where a control point sends commands to devlce(s). eventing 
(Step 4) where control points listen to state changes In devlce(s), and presen- 
tation (Step 5) where control points display a user interface for device(s). For 
more details on these functions, reference is made to UPnP Forum specifica- 
5 tion "UPnP^ Device Architecture 1.0", version 1 .0.1 , 6 l\4ay 2003. 

Referring to the UPnP Discovery, i.e. Step 1, the UPnP multicast 
messages are used by SSDP (Simple Service Discovery Protocol) in order to 
enable UPnP controlled devices to advertise their root/embedded devices and 
services and for UPnP control points to discover UPnP devices that are of in- 
10 terest to them. According to an embodiment in the UPnP system, the 
interworking unit IWU is, however, in step 304 of Figure 3 arranged to discard 
on the MHS Interface at least part of or all of the UPnP Discovery multicast 
messages that are originated in the HNvl. UPnP multicast messages are sent 
to a standard address and port 239.266.255.250:1900. The IWU is ananged 
1 5 to monitor the IP headers of the incoming packets and to prevent the transmis- 
sion of messages having said address as the destination IP address. Thus the 
IWU is a link layer device with IP snooping capabilities. The properties of the 
UPnP messages relating to the Discovery are described in Chapter 1.1.2, 
1.1.3, 1.2.2, and 1.2.3. 

The IWU is not allowing UPnP multicasting to enter MHS domain, 
but does not prevent multicasting in opposite direction to the HNvl domain. In 
one embodiment, the MHD fulfills the advertisement requirements of UPnP 
system and advertises by multicast messages itself at least when entering the 
UPnP system. The MHD may also make inquiries when It needs services from 
HNvl domain. The MHD keeps its existence known to the HNv1 control points 
and refreshes advertisements as needed. In fact, the MHD should be active to 
be known in UPnP network and obtain the cun-ent status from HNvl networi^. 
According to a further embodiment, the level of activity can be adjusted in the 
MHD, for instance by adjusting the transmission periods of the messages. In 
the following UPnP functions are illustrated for a MHD functioning as the con- 
trolled device in view of the UPnP system. For advertising itself, the MHD ac- 
cording to Figure 2a initiates the BT (Bluetooth) PAN fomiation, obtains an IP 
address (DHCP or Auto-IP), and thereafter advertises Its services via SSDP by 
one or more multicast messages. The IWU fonwards these multicast messages 
to the HVnl domain. Interested control points may then download the device 
description and subscribe to events In the MHD. After a time-out period ex- 
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pires, the PAN is turned to "sleep" mode. The MHD may refresh Its advertise- 
ment by sending a new multicast message. 

When an HNv1 (controlled) device (HND) advertises its services, 
the IWU receives the advertisement message and checks at least the IP desti- 
nation address. As the message is a multicast message, it is not forwarded to 
the MHD. The IWU treats a search query from an HNvi device functioning as 
a control point in a similar fashion, i.e. it is not fonA/arded to the MHD while it is 
a multicast message. 

However, the IWU is in step 305 arranged to forward unicast mes- 
sages intended for MHD originated in the HNv1. In this embodiment the IWU 
will foHA/ard unicast messages originated in the HNv1 domain (HND) and ad- 
dressed to the MHD. Thus the IWU in accordance of Figure 2a may wake up 
the Bluetooth PAN when it receives a unicast message to the MHD. For in- 
stance, when a (HNv1) control point wishes to perfomi an action on the MHD, 
It will send a SOAP (Simple Object Access Protocol) unicast message. The 
IWU snoops the IP traffic and notices that the control point tries to establish a 
unicast HTTP session with the MHD. As (based on check in steps 303-304 in 
Figure 3) the message is not a multicast message, the IWU will re-establish 
the BT PAN with the MHD. After the BT BAN is available, the IWU forwards the 
message to the MHD. The action is performed, and a response is transmitted 
to the control point After a predetermined time period the BT PAN between the 
MHD and the IWU goes to "sleep" mode. 

The MHD may also function as a control point in view of the UPnP 
system- In this embodiment the above-Illustrated principles apply; the IWU will 
foHA^ard all unicast messages to and from the MHD and multicast messages 
only from the MHD. Thus the MHD may send search queries, receive GENA 
(General Event Notification Architecture) events and respond to SOAP actions 
via the IWU to an HNv1 device but will not receive multicast advertisements 
from HNv1 devices or search queries from HNv1 control points. 

In one embodiment not described in Figures 1 and 2, some or all of 
the above-Illustrated features relating to preventing transmission of multicast 
and/or broadcast messages is implemented in a system where both devices 
(MHD, HND) use the same networking technology. Thus the intermediate node 
does not have to provide any adaptation between two different transmission 
protocols. The intermediate node may then support one-to-one associations 
between the IWU and the device MHD, HND. Examples of such associations 
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are the IEEE 802.11 association between a mobile terminal and an access 
point or the association between the LAN MAC of a networic caiti and a single 
LAN MAC of a switch. The Intermediate node may leam by inspecting layer 2 
traffic (possibly also IP snooping) using heuristic means, which attached de- 
vices belong to the HNvl domain and which belong to the MHS domain. Then 
the transmission of the multicast and/or broadcast messages is prevented for 
the MHDs. For instance, both sides of the intermediate node may be WLAN, 
Ethernet or BT and the above-illustrated optimization features may still be ap- 
plied. 

It will be obvious to a person sicilled in the art that, as the technology 
advances, the inventive concept can be implemented in various ways. The In- 
vention and its embodiments are not limited to the examples described above 
but may vary within the scope of the claims. 
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CLAIMS 

1. A method of arranging communication in a locai area networl^ing 
system comprising a first device, a second device and an intermediate node 
for arranging data transmission between tlie first device and the second de- 

5 vice, wherein at least the second device is arranged to multicast and/or brpad- 
cast messages to devices in the system, characterized by 

preventing the transmission of at least some of multicast and/or 
broadcast messages to the first device by the interworl^ing means. 

2. A method as claimed in claim 1, characterized in that 

10 the intermediate node is arranged to connect networlcs that use dif- 

ferent data transmission protocols. 

3. Amethodasciaimed inciaim 1 or2,characterized by 
checldng the destination IP address of a received pacl<et by the in- 

terworlcing means, 

15 comparing the destination IP address of the packet with at least one 

predetermined multicast/broadcast address, and 

preventing the transmission of the packet if the addresses match. 

4. A method as claimed in claim 1,2 or 3, characterized in 
that the first device belongs to MHS domain of a UPnP system and the second 

20 device belongs to the HNvl domain of the UPnP system. 

5. A method as claimed in claim 4, characterized in that the 
transmission of UPnP discovery multicast messages to the first device is pre- 
vented. 

6. A local area networking system comprising a first device, a sec- 
25 ond device and an intermediate node for arranging data transmission between 

the first device and the second device, wherein at least the second device is 
arranged to multicast and/or broadcast messages to devices in the system, 
characterized in that 

intermediate node is arranged to prevent the transmission of at 
30 least some of multicast and/or broadcast messages to the first device. 

7. A data processing device for a local area networking system, the 
data processing device being an intermediate node arranging data transmis- 
sion between a first device and a second device characterized in that 

the data processing device is arranged to prevent the transmission 
35 of at least some of multicast and/or broadcast messages to the first device. 
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8. A data processing device according to claim 7, character- 
ized intiiat 

tlie intermediate node is arranged to connect networl<s that use dif- 
ferent data transmission protocols. 

9. A data processing device according to claim 8, character- 
ized in that 

the data processing device is arranged to perform data transmission 
between IEEE 802-based network to which the second device belongs to and 
a Bluetooth network to which the first device belongs to 

10. A data processing device according to claim 7, 8, or 9, char- 
acterized in that the data processing device is arranged to check the des- 
tination IP address of a received packet by the interworking means, 

the data processing device is arranged to compare the destination 
IP address of the packet with at least one predetermined multicast/broadcast 
address, and 

the data processing device is arranged to prevent the transmission 
of the packet if the addresses match. 

11. A data processing device according to any preceding claim 7 - 
10, characterized in that 

the data processing device is arranged to provide data transmission 
between the first device belonging to MHS domain of a UPnP system and the 
second device belonging to the HNvl domain of the UPnP system. 

12. A data processing device according to claim 11, character- 
ized in that 

the data processing device is arranged to prevent transmission of 
UPnP discovery multicast messages to the first device, and 

the data processing device is arranged to forward at least those 
broadcast messages relating to address acquisition to the first device. 

13. A data processing device according to any preceding claim 7 - 
12, c h a r a c t e r i z e d in that 

the data processing device is arranged to compare one or more 
properties of the message to the properties specified in predetermined trans- 
mission conditions to determine whether the message should be transferred to 
the first device. 

14. Module for controlling a data processing device for a local area 
networking system, characterized In that 
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the module is arranged to cause the data processing device to pre- 
vent the transmission of at least some multicast and/or broadcast messages 
from a second device to a first device. 

15. A computer program, product for controlling a data processing 
device for a local area networking system by executing the program code in- 
cluded in the computer software product In a processor of the data processing 
device, characterized in that the computer software product comprises: 

a program code portion for causing the data processing device to 
prevent the transmission of at least some multicast and/or broadcast mes- 
sages from a second device to a first device. 



ABSTRACT 

The invention relates to a method of anranging communi- 
cation in a local area networking system comprising a first 
device, a second device and an intermediate node for ar- 
ranging data transmission between the first device and the 
second device. The second device is arranged to multicast 
and/or broadcast messages to devices in the system. The 
transmission of multicast and/or broadcast messages to 
the first device is prevented by the interworking means. 
(Figure 3) 
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